A common attack on computer network security is one in which an attacker spoofs a “From:” address on an e-mail message in an attempt to trick the recipient of the message into trusting the message as authentic and, based on this misplaced trust, take action beneficial to the attacker. The success of these attacks is due not only to the usual disparity in technical skills of the attackers and their intended victims, but also to the attacker's use of a ‘From’ address that the victim trusts. In one attack in March 2016, a senior financial official of an American company was tricked into wiring $3 million to a bank in China on the mistaken belief that the company's new CEO had sent an e-mail to authorize the payment. Spoofing is also common in ransomware e-mail attacks.
Existing efforts to control spoofing that do not require the participation of the user include (SPF) Sender Policy Framework (created in 2003) and (DKIM) Domain Keys Identified Mail (created in 2004 by an industry consortium) And (DMARC) Domain-based Message Authentication, Reporting and Conformance (2012).
SPF encourages the registration in an accessible SPF record of just which server is authorized to send mail for a particular domain name. Servers receiving e-mail can then refer to the SPF record to verify that the mail was sent from the authorized server, rather than being forged, by comparing the domain name of the spoofer's server to the domain name shown in the ‘From’ line in the email. If the domain names are not the same the e-mail can be flagged prior to delivery or simply rejected, i.e. not delivered.
While the purpose of SPF is to verify that the sending server shown in the From line is actually the server from which the e-mail was sent, DKIM uses asymmetric encryption to verify that the e-mail client computer sending the e-mail is the authorized client by using a private key to encrypt the address line which is decrypted by the receiving server using a public key. The sending server also sends a hash of the message to verify that there was no tampering enroute by a third party.
The problem with these efforts was the absence of a standard way among e-mail hosts for dealing with messages failed by SPF and/or DKIM, with the result that most if not all failed messages simply went through to the recipient whether flagged as a problem or not flagged. Then Domain-based Message Authentication, Reporting and Conformance (DMARC), in 2012, set out to remedy this problem, providing a standard way for servers using SPK and/or DKIM to deal with failed messages. Users of DMARC can set their servers to choose one of three rejection policies based on information provided by SPK and DKIM: “None, Quarantine, or Reject” for mail that DMARC fails.
Yet, because of the fear of being blamed for rejecting legitimate mail, many e-mail hosts who use DMARC are loath to set a policy of Reject or even Quarantine. And some e-mail hosts simply avoid SPK, DKIM and DMARC, saying that it creates other problems for them, as well.
SPF, DKIM and DMARC are efforts to create a standard system to eliminate spoofing by gathering and using data from abuse found anywhere on the internet. It is a helpful but complex effort that requires significant internet traffic, requires continued careful attention to detail by email hosts but has yet to conquer the problem. Recently, a Wikipedia article on spoofing estimated that the effectiveness of efforts to identify spoofing vary from 8% to almost half of spoofed messages.
Much of the reason that e-mail hosts have not all embraced SPF, DKIM and/or DMARC is not technology but the human factor. First many systems administrators at e-mail hosts find these efforts very complicated and difficult to troubleshoot. And some are loath to depend on these methods because they think these methods will interfere with their own management of their servers and create problems in their relations with their clients. Even if an e-mail host does use any or all of these internet-wide efforts to stop abuse, many such hosts simply flag the mail and send it on to the client—preferring what is called a ‘soft block’ rather than a ‘hard block’ (outright rejection) of failed messages in order to avoid blame for any wrongly blocked messages.
While clearly helpful in attacking the spoofing problem by their focus on identifying the abusers and stopping them from sending spoofed mail, these efforts do little to prevent harm from those messages that do reach the intended recipient. And, has been shown by ransomware attacks in recent months, a great deal of harm and fear can be done too quickly for these methods to control. What is needed is a locally applied method that will stop new attacks without any need for alteration, will be easily understood and managed by e-mail server administrators, and allow them to deliver every e-mail message to the intended recipient while preventing a recipient response to the text, links and attachments in a spoofed message. This would relieve the email host from the fear of complaints about blocking of messages and also be a powerful means of reducing the harm from spoofing, including ransomware spoofing. It would provide a powerful complement to existing efforts.